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An important property of programming language semantics is that they should be compositional. 
However, unstructured low-level code contains goto-like commands making it hard to define a se¬ 
mantics that is compositional. In this paper, we follow the ideas of Saabas and Uustalu Q to structure 
low-level code. This gives us the possibility to define a compositional denotational semantics based 
on least fixed points to allow for the use of inductive verification methods. We capture the seman¬ 
tics of communication using finite traces similar to the denotations of CSP. In addition, we examine 
properties of this semantics and give an example that demonstrates reasoning about communication 
and jumps. With this semantics, we lay the foundations for a proof calculus that captures both, the 
semantics of unstructured low-level code and communication. 


1 Introduction 

Electronic devices are increasingly integrated into our daily lives. Most of them are “invisible” and 
would, ideally, run forever once deployed. Often this is not a crucial feature, as a smart phone or a server 
can be restarted if they crash. But in cases where the system cannot be restarted, the correctness of those 
systems needs to be ensured. Examples of such cases are medical devices and automotive systems. 

By the correctness of a system we mean a formal conformance relation between an abstract speci¬ 
fication and its implementation. We consider the specification language of Communicating Sequential 
Processes (CSP) (O as suitable technique to describe and verify the communication behavior of con¬ 
current programs. The advantage is that properties can be verified on fhe absfracf model of CSP and 
conformance ensures fhaf fhese properties are preserved fo fhe implemenfafion level. We assume as in 
our modeling and verificalion approach presenfed in 01 fhaf, having refined fhe CSP specificafion suffi- 
cienfly, if is implemenfed in a high-level language such as C-i-i- and fhen compiled fo a low-level language 
such as EEVM. Instead of showing conformance befween a high-level language and CSP, we show con¬ 
formance of fhe corresponding low-level represenfafion insfead. This approach has fhe advanfage fhaf a 
complex formal semanfics of a high-level language can be avoided and lightens fhe gap befween verified 
code and executed code. We choose an EEVM-like unslruclured language fhaf we previously presenfed 
in 0 because if is platform independenl. In order fo model communicaling programs, we have included 
a generic insfrucfion fhaf allows for communicalion befween unslruclured programs. 

In Ihis paper, we give a formal denolafional semanfics fo fhe implemenfafion level focussing on com¬ 
municaling unslruclured code. The parlicular challenge lies in fhe facf fhaf denolafional semanfics for 
unslruclured code are usually nol composifional because of fhe presence of some varianf of fhe goto 
command. This usually requires fhe whole code available when showing properties. Eurthermore, we 
consider communicalion. To overcome fhe firsl problem, we slruclure unslruclured code following ideas 
from Saabas and Uuslalu Q. While fhey define a composifional bigsfep semanfics for an unslruclured 
language, we define a denolafional semanfics based on fixpoinls, which additionally copes with commu¬ 
nication and nontermination. The latter features are close to the approach taken in CSP. As we require 
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our approach to enable automation and also to gain confidence in the correctness of our semantical con¬ 
struction, we formalize all results in the theorem prover Isabelle/HOL0 P6i|. Our denotational semantics 
gives us the groundwork for developing a compositional proof calculus that not only allows to formu¬ 
late properties about possible states of unstructured programs but also allows us to reason about the 
communication behavior using traces. 

The rest of this paper is structured as follows. Related work is dicussed in the next section. In Sec¬ 
tion [3l we give necessary background information about structured code, the concept of denotational 
semantics, CSP, and Isabelle/HOL. In Section |4l we introduce our low-level language, which we call 
Communicating Unstructured Code and for which we define a smallstep operational semantics in Sec- 
tion l4.ll Our main contribution is described in Section l4~2] where we introduce our denotational semantics 
for Communicating Unstructured Code. In Section 12 we analyze the denotational semantics and prove 
conformance to the intuitive operational semantics. In Section [2 we define a rule to ease argumentation 
about the semantics. This gives an idea what a future calculus will look like. We illustrate the utility of 
our denotational semantics in Section |2 We give a conclusion and pointers to future work in Section [2 

2 Related Work 

There are some attempts to give unstructured code a semantics for later verification. Tews rjl devel¬ 
oped a compositional semantics for a C-like language with goto, which is used to verify Duff’s device. 
However, this approach does not model communication. 

Saabas and Uustalu 0 present a compositional bigstep semantics of an unstructured language. To 
this end, a generic structuring mechanism for the code is presented, which makes the semantics compo¬ 
sitional and also allows for a compositional proof calculus. Although they formally relate a high-level 
and a low-level language, they do not relate a process specification with the low-level language. Com¬ 
munication is not considered. 

A denotational semantics and a proof calculus for a high-level language with communication were 
already defined by Zwiers ifTTl . As low-level code is not considered, the semantics is not directly appli¬ 
cable, but we will follow this approach when designing a proof calculus in future work. A preliminary 
rule of this calculus is presented in this paper. 

Our unstructured language that we introduce in Section |4]is based on our previous work |2I enhanced 
with communication capabilities. The approach in l|2l focuses on a smallstep and a bigstep operational 
semantics based on which a compositional proof calculus is built. We used similar semantics in |T| to 
show correspondence between unstructured code and (Timed) CSP processes. In |[T1 we used events as 
observation points, but did not consider actual communication. In addition to considering also commu¬ 
nication, we aim in future at relating unstructured code and CSP processes based on our denotational 
semantics, which facilitates refinement-based verification instead of bisimulation equivalence as used 

inim. 

3 Background 

In this section, we introduce the concept of structuring unstructered code and give brief introductions to 
denotational semantics and Communication Sequential Processes. 

'when the intended Hoare calculus (see Section |2 is finished, we plan to publish the Isabelle theories in the Archive of 
Formal Proofs (http: //afp. sourcef orge. net/ ). If you are interested in the current version of the theories, please contact 


us. 



N. Jahnig, T. Gothel & S. Glesner 


11 


3.1 Structured Code 

It is difficult to obtain a compositional semantics for unstructured low-level code, as compositionality 
usually involves splitting the code into parts according to its structure. The simplest structure is a list 
of instructions, which can be split into head and tail. But also in unstructured code there are blocks 
of instructions that belong to the same functionality, and it is desirable to reason about such blocks 
as components and not instruction after instruction appended to the previous code (as it would be the 
case for lists). Therefore we choose a structure which allows for those blocks to be reasoned about as a 
component, namely trees. To this end, we follow a similar approach to the one presented in f7l by Saabas 
and Uustalu. 

In their approach, every instruction has a unique label (e.g., a natural number) that refers to it, and the 
semantics depends on an explicit program counter that holds the label of the next instruction to execute. 
After executing one instruction, the program counter is usually incremented by one so that it points to 
the next instruction. Only control flow instructions, e.g., goto can set the program counter to a different 
value. This way, conditionals or loops can be constructed. 

An unstructured program can be intuitively formalized as a set of labeled instructions, i.e., pairs 
of labels and instructions. All labels are assumed to be unique. The shortcoming of this formalization 
is that there is no useful shucture on which induction can be applied. E.g., as the whole code needs 
to be considered all the time due to the goto instructions, the operational smallstep semantics on it 
(see Section KB is not compositionaJl with respect to the program. So a denotational semantics on 
unshuctured code will also not be compositional. 

To overcome this problem, we inhoduce a tree shucture on the instructions. Let code adhere to the 
following grammar 

code ::= {label :: instruction) \ code®code 

where 0 is the sequential composition operator. As described in the next subsection, we can use this 
shucture to reason about the single components (i.e., subhees), and compose their meaning, thus obtain 
compositionality. To make sure that the structure does not influence the semantics of a program, all 
possibilities to structure a given set of inshuctions must have the same meaning (for our semantics this is 
a corollary of the conformance proved in Section lSTTI) . We can choose which shucture on the code fits our 
needs best. Usually, this is a structure where as many jumps as possible are inside a component. By this, 
the enhy and exit possibilities for each component are minimized. This will help in future work when 
choosing pre and post conditions, as for known code, not every instruction label needs to be considered 
as a possible enhy point. 

It is important to note that even though we call 0 the sequential composition (opposed to a pos¬ 
sible parallel composition), it is not the sequential composition known from shuctured programming 
languages. The important difference is that inshuctions combined with 0 can create loops, if branch 
instructions are contained. As loops are only dealt with in rules about 0, we call 0 the looping construct 
of the language. 

To be able to relate structured and unshuctured code, a projection U^c from structured code to labeled 
instruction sets is defined, which “forgets” the shucture. Observe, that the operation 0 is only defined 
for structured code. 

Having introduced the concept of structured code in our setting, we are able to define a compositional 
denotational semantics of our low-level language. It is particularly amenable to fixpoint induction, which 
we describe subsequently. 

^Compositionality here refers to “sequential” compsitionality. In this paper we do not consider “parallel” compositionality. 
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3.2 Denotational Semantics 

In contrast to operational semantics, which describes how single instructions manipulate the state, in 
denotational semantics each program is assigned a function (its denotation) which maps an initial state 
to the meaning of the program. This can be, e.g., a final state or a set of traces as in the case of CSP. As 
denotational semantics can be characterized via operational semantics and operational semantics can be 
defined compositionally, boundaries between the two can be vague. 

To be able to assign a denotation to programs containing loops, a function F from denotation to 
denotation is considered, which extends the denotation with the semantics for one execution of the loop. 
The least fixpoint of this function F is then the denotation of the program containing the loop. 

To define a least fixpoint, we use a chain-complete partial order on the denotations. This is usually 
obtained by lifting the chain-complete partial order on the states, i.e., co-domain of the denotations. In 
general, the resulting denotation may not be computable in finite time, but fixpoint induction can be used 
to reason about properties of denotations of programs containing loops. Fixpoint induction (or Scott 
induction, e.g., in ifTOll l requires the function F to be continuous, and the property of interest I to be 
admissible, i.e., if I holds for all elements of a chain, then 1 also holds for the supremum of the chain. 
Finally, for every denotation /, if /(/) holds, then I{F{f)) has to hold as well (step case). 

3.3 Communicating Sequential Processes 

Note: CSP is not necessary for the following definitions, but is helpful as the denotational semantics is 
designed with CSP in mind. 

Communicating Sequential Processes (CSP) [8] is a process algebra, originally introduced in |!5l|. It 
is designed specifically to model concurrent processes, which communicate via events. Communication 
is synchronous and thus can be used to synchronize processes or exchange data. 

Processes can be constructed from the basic processes STOP and SKIP and using operators such as 
event prefixing, external and internal choice, interrupts, and sequential and parallel composition. 

CSP is suited for modeling various layers of abstraction as described in [8]: Specification, design and 
implementation, where specification is most abstract, and implementation can be directly converted into 
program code. Abstraction levels can be mixed in a process, and CSP processes across all abstraction 
levels can be put in relation via refinements. Informally a process Q refines a process P, if fhe behavior 
of process 2 is a subset of the behavior of process P. 

There are two important semantic models for CSP with raising complexity and expressiveness: 1) 
The trace semantics, which describes the communication histories of processes, which we use in this 
paper. 2 ) The stable failures semantics, which additionally captures the events a process can refuse after 
a trace. In this paper, we focus on traces, but we plan to extend it to failures in future work. 

The automatic refinement checker FDR3 tJl supports refinement checks for both mentioned seman¬ 
tics. 

4 Communicating Unstructured Code 

In this section, we introduce Communicating Unstructured Code (CUC), which we adapt from our pre¬ 
vious work @ and enhance it with a communication primitive. 

On the one hand, we want to be as close to low-level code as possible to reduce the gap between 
executed code and verified code. On the other hand, we want to focus on communication and not its 
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implementation. Therefore, we decided to use an unstructured language with a higher level construct for 
communication. 

We keep our language generic and simple. Though being simple, it is powerful (as it contains con¬ 
ditional branches). This simplicity allows for manageable semantics design and proofs. Our language 
consists of three basic instructions: 

instruction := do f | cbr b m n | comm ef f 

In the following, we give an informal explanation of these instructions. 

do f - The command do is a generalized assignment, f is a function from state to set of states and it 
is applied to the current state. The resulting state is one element of the set returned by f. The instruction 
can thus be thought of as a nondetemiinistic multiple assignment. 

cbr b m n - The instruction cbr is a usual conditional branch. If the function b from state to bool 
evaluates to True then the program counter is set to m else to n. 

comm ef f - The command comm is the communication primitive. It communicates an event from 
the result of ef and then changes the state according to f, where ef is a function from state to set of 
events and f is a function from state and event to state. Observe that here f is deterministic to ease 
reasoning. We reserve nondeterminism of the successor state to the instruction do f. 

The instructions do f and comm ef f are abstract instructions (instructions schemes), which can be 
instantiated. For example, the instance on the left models an assignment of y to x. The instance on the 
right adds r to y and stores the result to z. 

“x:=y” “z:=x + y” 

do (Aa. a[x ^ a(y)]) do (Aa. a[z ^ a(x) + a(y)]) 

The next instance defines an input of values of type T over channel in storing the value in variable x. 

“x := input(m :: T)” 

comm (Aa. {in.v \ v £T })(Aa ev. o[x val{ev)]) 

In the last example and in Section|7l events are of the type channels x values (written in the dot-notation 
channel.value as usual in CSP). This is just a convenient instantiation, as there are no strucutral require¬ 
ments on the type of events (also as in CSP). Apart from the chosen type of events, there is no concept 
of channels in CUC. 

In this section, we have presented the instructions of our language and have given its informal se¬ 
mantics. In the next section, we first define fhe more infuifive smallsfep semantics fo capfure our ideas, 
and fhen define fhe denofafional semantics in Secfion 14.21 as if fifs beffer our ulfimafe goal fo relate 
CUC programs and CSP processes. In Secfion l5Tl we show conformance befween fhe smallsfep and fhe 
denofafional semantics, fo ensure fhaf fhe denofafional semanfics adheres fo our ideas. 

4.1 Operational Smallstep Semantics 

As we consider unsfrucfured code, a program is given as a sef of labeled instructions, i.e., pairs of 
identifier (label) and insfrucfions. We assume fhaf fhe idenfifiers are unique. 

We model fhe slate as consisfing of Ihree parts: The usual slale (i.e., fhe values of variables), fhe 
program counfer, and fhe Irace (i.e., fhe communicalion history as a lisl of evenls). Observe fhaf each 
inslruclion roughly corresponds fo one part of fhe slate: do changes fhe variables, cbr fhe program 
counter, and comm fhe Irace. The excepfions are fhaf bolh, do and comm, increase fhe program counter 
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by one, and that comm can also change the state to store communicated values. See Figure [T] for the 
smallstep semantics, which captures the behavior described in Section |4] Each instruction can only be 
applied if the pc is pointing to its label. We explain the rules in detail: 

S-DO - Only the variables are changed, possibly nondeterministically, according to /. Traces stay 
the same and the program counter is increased by one. 

S-CBR - There are two rules, one for the case when the condition b evaluates to True, and one when 
it evaluates to False. In both cases only the pc is changed accordingly, and variables and trace remain 
the same. 

S-COMM - ef determines which events are offered for communication. The communicated event is 
appended to the existing trace. The successor state is calculated according to /, this time deterministically 
and additionally depending on the communicated event. / is deterministic to focus on communication. 
Again, the program counter is increased by one. 

a if := (a, t?) G smallstep{code) 

if "do /) € code t G /(s) 

--- S-DO 

(tr,s,£) 

(£ :: cbr bmn) G code bis) = True 
---S-CBR True 

{tr,s,i) {tr,s,m) 

[f :: cbr bmn) G code b{s) = False 
---S-CBR False 

{tr,s,£) {tr,s,n) 

(£::comm eff) Geode evGef{s) trt = tVs^ev t = f{s,ev) 

---S-COMM 

{trs,s,i) {trt,t,£+l) 


Figure 1: Smallstep Semantics for CUC 

The smallstep semantics defines the executions of single instructions. To relate the operational se¬ 
mantics with the denotational semantics we need the multistep relation, which is the reflexive transitive 
closure of the smallstep relation, and defines the semantics for executions of a set of instructions. See the 
multistep semantics in Figure|2] The first rule (M-BASE) is the base case, stating that every step is reach¬ 
able from itself (reflexivity); the second rule (M-STEP) is the step rule, stating that if a state is reachable, 
its smallstep successors are reachable, too (transitivity). Please note that the operational semantics is not 
defined for ©, as the operational semantics is defined on unstructured code. 

4.2 Denotational Semantics 

We presented previously a compositional bigstep semantics for a low-level language without commu¬ 
nication in ||2|. In contrast, we require our extended semantics with communication to be close to the 
denotational CSP semantics. To this end, we define a denotational semantics which captures the state 
information but also the finite traces of program executions. 
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code 


o -:= (a, ■&) G multistep{code) 


M-base 


{tr,s,£) 


{tr,,s,Q {tru,u,Q {tru,u,£u) 

{trs,s,£s) ^^*{trt,t,£t) 


Figure 2: Multistep Semantics for CUC 


M-step 


D-do 

[£ :: do /1(S) ^.= Sl^{{tr,t,£+ 1) | {tr,s,£) £S At £ f{s)} 

D-cbr 

\£ :: cbr b m nl(S) := SU {{tr,s,pc) \ {tr,s,£) £ SA {b{s) Ape = my -^b{s) Ape = n)} 

D-comm 

\£ :: comm e//](S) := SU {{tr'~'ev,t,£+ 1) 1 {tr,s,£) £ S Aev £ ef{s) At = f{s,ev)} 
D-seq 

leodei(Beode2l ■= [pd. extend{eodei,eode2) (d)) 

D-ext 

extend{eode\,eode2) (d) := AS. SUr/([[cor/ci](S)) Ur/dcor/caK*^)) 

Figure 3: Denotational Semantics for CUC 


See Figure [3] for the denotational semantics defined on the structured variant of CUC. The semantic 
function [■] maps eode to its denotation. We use the p operator to denote a least fixpoint and the under¬ 
lying chain-complete partial order is the point-wise subset relation (f < g ■= VS. /(S) C g[S) where S is 
a set of states). 

The smallstep semantics operates on single states, but we use sets of states in the denotational se¬ 
mantics to capture nondeterminism. Furthermore, we require sets also as input of the denotations so 
that we are able to chain functions directly. This facilitates sequential composition, as introduced in the 
background. Finally, we can keep track of all intermediate states and the corresponding traces, by simply 
extending the set input to the denotation (“5 U” on the right-hand side of function definitions). This 
construction is also used in CSP and enables prefix elosure (see Section l5.2.3l) . 

The single step rules D-DO, D-CBR and D-COMM are very similar to their operational semantics 
counterparts. For all states where the program points to the label £ of the instruction, all successor states 
are added to the resulting set. 
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extend (D-ext) extends a given denotation d with the executions of the two components code\ and 
code2 respectively, {extend corresponds to the function F in Section [3]2l) With its help we describe in 
D-SEQ the sequential composition 0 which is modeled as fixpoint of extend and thus as the repeated, 
possibly alternating application of the two components. Remember, that © is also the looping construct 
(see Section [XT]) . 

We have presented the operational and denotational semantics and show important properties of the 
latter in the next section. 

5 Analysis of the Denotational Semantics 

Our longterm goal is to define a refinement proof calculus, which relates CUC programs and CSP pro¬ 
cesses. This can only succeed, if we can ensure that the CUC semantics is close enough to the CSP 
semantics. Therefore we show a property related to structured code and two selected properties of CSP 
for the denotational semantics: i) Compositionality, which is also important for the future construction of 
a compositional calculus, and ii) prefix closure, which will be imporfanf when showing fhaf a CUC pro¬ 
gram refines a CSP process considering failures (which allow for fhe verificalion of liveness properfies) 
in fulure work. We sfarf ouflining fhe proof fhaf fhe denofafional semantics conforms fo fhe operafional 
mulfisfep semantics, fo ensure fhaf fhe ideas formulated in fhe smallsfep semantics are also capfured by 
fhe denofafional semantics. 

5.1 Conformance Proof 

By conformance we mean fhaf, sfarfing in an arbifrary sfafe, fhe reachable slates Ihrough fhe denola- 
fional semanlics and fhe mulfisfep semantics of a given slrucfured code and ils unsfrucfured projection 
respeclively are fhe same: 

{tr,,t,pc,) G lcode}{{{lrs,s,pCs)}) {trs,s,pCs) ^--%* {lrt,t,pct) 

We oulline fhe Iwo direcfions of fhe conformance proof. We have formalized full proofs in Is- 
abelle/HOL. Firsl, we argue fhaf all slates in fhe relumed sef of a denolalion are reachable Ihrough fhe 
mulfisfep relation, and Ihen fhe inverse direction. As we use fhe slrucluring technique for unsfrucfured 
code from Saabas and Uusfalu f7], we follow Iheir proofs adapfed for our denofafional semanlics. In 
bolh directions we use fhe similarily of single steps of fhe Iwo semanlics. The inleresling case in each 
direcfion is fhe sequenlial composition case. 

Denotational Semantics Multistep We perform induction over the structure of code. The in¬ 
duction hypothesis states that for the subcomponents the denotational semantics implies the multistep 
semantics. To show the sequential composition case, we combine the hypotheses for the subcomponents 
using fixpoint induction. 

Multistep =)> Denotational Semantics The main problem is that the multistep relation operates on 
instruction sets, thus is insensible to the structure of code. We need to extend the multistep relation with 
a step counter k, in order to invoke induction over the number of steps. 

We still perform induction over the structure of code, but within each case we use case-distinction or 
induction over k, respectively. 
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An important insight from Saabas and Uustalu f71 for the induction in the case of the sequential 
composition is that each time we point into one part of the code, we make at least one step (in multistep), 
and thus in the other part, we have less steps left than we started with. This way we can decrease the 
value of k and use the induction hypothesis for the single component and for a smaller k, respectively. 

5.2 Properties 

In this subsection, we show that © is associative and commutative, and that the denotational semantics 
is compositional and prefix closed. 

5.2.1 Associativity and Commutativity 

Corollary 1 (Associativity and Commutativity). © is associative and commutative, i.e., 
'icodei,code 2 ,code$: 

Icodei (Bcode 2 l = \code 2 ®code\\ 

\{code\ ® code 2 ) ® code-il = \code\ © {code 2 ©cor/ea)] 

Proof. This follows directly from the conformance. As U^c removes all structure, any structure on a 
given set of instructions has the same semantic function. □ 

5.2.2 Compositionality 

A semantics is compositional, if the semantics of a combination of components is defined direcfly using 
the semantics of the components and not details of them. 

Theorem 2 (Compositionality). The denotational semantics is compositional, as the semantic function 
for sequential composition (D-SEQ, D-EXT) uses solely the semantic functions of the components and 
does not need further details about the components. □ 

5.2.3 Prefix Closure 

A set of traces is prefix closed, if for each trace in the set, all prefixes are confained in fhe sef, too. We 
need fo slighfly adapf fhis definifion, as fhe argumenf sef of fhe denofafion does nof need to be prefix 
closed. So we formulate fhe properly as an invarianl over fhe semantic functions (see Secfion for a 
definifion of invarianfs): 

Theorem 3 (Prefix Closure). If the argument set S is prefix closed, so is the returned set Icor/eKS). 

Proof. The adapted prefix closed properly holds: We only need fo fake a closer look al D-COMM, as if 
is fhe only rule changing fhe frace. Looking al D-COMM, we see fhal fhe yielded sef is a union of fhe 
argumenf sef S and all newly calculaled sfales. As fhe new slates only confain Iraces fhal are conslrucfed 
by appending fo existing Iraces, we gel by using fhe assumplion fhal all fhe prefixes of all conslrucfed 
fraces are also in fhe relumed sef. □ 

If we now assume fhal fhe sef of initial slates only conlains empty Iraces, lhan fhe semantics for a 
given program relurns sels which are prefix closed. 

We have shown imporlanf properlies, which are a prerequisite fo relale fhe denolafional semanfics 
and CSP and have ouflined a proof fhal fhe denolafional semantics relates fhe same sfales as fhe smallslep 
semantics. In fhe nexl secfion, we give a preliminary rule for an invarianl-based Hoare calculus. 
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1 :: do (Aa. {a[free ^ True]}) 

0 2 :: comm ef f where 

ef = {Xa. {in.x \ o{free) =Tme/\x ^T} 

U {out.x I o{free) = False A;c = o{buffer)}) 
f = (Aa event, case event of 

I in.x ^ a [buffer <r- x,free <— False] 

I out.x a [free <r- True]) 

0 3:: cbr (Aa.True) 2 2 

Figure 4: One Place Buffer in CUC 


6 Towards a Hoare calculus 


Reasoning with semantics directly is generally complex. Therefore a proof calculus is usually introduced 
to make verification of properties manageable. We leave the proof calculus for future work, but we define 
an invarianf and presenf a preliminary rule in Ibis secfion. 

In order fo show properties of communicating, possibly nonferminafing programs fradifional Hoare 
logics wifh pre- and posfcondilions are nol well suifed, as fhe posfcondifion may never be reached. This is 
why we enhance fhe Hoare calculus wifh invarianfs fo asserf properfies over fhe communicafion hisfory. 
Using a calculus wifh invarianfs, we are sfill able fo express properfies abouf fhe program behavior even 
if fhe posfcondifion is never reached. This approach is, e.g., faken by Zwiers IHH . Invarianfs come 
quife nafurally fo reasoning abouf unsfrucfured code, as fhe sequential composifion is also fhe looping 
consfrucf, and Iherefore already fhe sequential composifion rule in fhe Hoare calculus defined by Saabas 
and Uusfalu fT\ uses invarianfs in pre- and posfcondifions. 

We say an invariant /, holds for fhe semanfic function of code, if if holds before, during, and affer 
fhe execution for arbifrary inifial sfafes. Lef / be a predicate on a state, fhen we define formally: 


V5. (ffs G S.l{s)) (Vt G lcodej{S).I{t)) 
I : |cor/e]] 


INV Intro 


In fhe example in fhe nexf secfion, we will use fhe following rule fo reason abouf fhe componenfs of 
sequenfial composifion separafely: 


I: Icor/eJ I : Icor/eal 

-z--- iNV © 

I: lcodei®code2j 

We have proven soundness of fhe rule iNV 0 in Isabelle/HOL. The infuifion is fhaf sequenfial com- 
posifion leads fo fhe repealed execution of fhe code sections code\ and code 2 in a possibly allernafing 
order, and if bofh keep fhe invarianf valid, so does fhe sequenfial composifion as if is compositional. 
Admissibilily of fhe invarianf is ensured, as we defined if on single slates. 

7 Example 

We demonslrale fhe applicabilily of our formal framework as presented above and show for a simple 
implemenlalion (written in CUC) of a one-place buffer lhal if is correcl, i.e., if only oulpuls whal was 
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input before. We do so using the denotational semantics and a preliminary rule from the proof calculus. 
See Figure |4]for the code listing (we define © to be right associative). The code implements a buffer that 
can hold one value of type T. We explain the code line by line: 

(1: : do) - This is the initialization. The boolean/ree indicates that the buffer is ready to store data. 

(2: : comm) - The comm-instraction both offers the events and changes the state after the communication 
happened. The events offered by ef are all values of type T on channel in if the buffer is free, else the 
output event with the value stored in the buffer is offered. According to the event communicated, it either 
stores the input value and sets the buffer to not free, or it just sets the buffer to free. 

(3: :cbr) - The conditional branch is used in this case to model an unconditional branch and always 
jumps back to the comm-instruction at label 2. 

We show that, starting with an empty trace and with the program counter pointing to the first in¬ 
struction (as described by the assertion Pre), only values that are input are also output (as described by 
Inv): 


Pre{tr^O ^pc) '= tr = {) A pc = \ 

Inv{tr, a,pc) := tr € TReven GTRodd 
where TReven ■= {in.x'^ out .x \x £T}* 
and TRodd •= {tr^in.x \ tr E TRgven Ax E T} 

The operator •* being the Kleene Star, TRgygn is the set of all even traces, i.e., where every input of 
a value is followed by the output of the same value. TRodd is the set of odd traces, which are the even 
traces with an appended single input. 

We name instructions by their label, e.g., in this example instruction 3 means (3:: cbr (Aa. True) 2 2). 

Following the structure of the code, we start reasoning about the sequential composition of instruc¬ 
tions 2 and 3, and then combine it with instruction 1. 

To show Inv we need to strengthen it by adding state and program counter information, as the in¬ 
structions depend on the state and on the program counter. This gives us a stronger invariant, denoted 
h. 3 , which we will use as invariant for instructions 2 and 3. 

I 23 {tr,a,pc) := {treTReven A O{free) = True 
V tr E TRodd A o{free) = False 

A O {buffer) = x A3tr' .tr = tr'~in.x) 

Ape & {2,3} 

We use the rule iNV © to reason about instructions 2 and 3 separately. 

/ 2 , 3 : [2 :: comm ef f} - Either we start with an even trace (E TR) and free = True, then we accept 
input and the second disjunct holds or we start in the second disjunct with an odd trace, output the 
corresponding value, and then end up in the first disjunct. In both cases we end up with pc = 3. 

72,3: [3 :: cbr (Aa. True) 2 2]] - cbr does neither change state nor trace, only the program counter is 
set to 2, so the validity of 12,3 is preserved by instruction 3. 

We are left to show that instruction 1 brings us from the initial state to the 72,3: Assume Pre holds, 
then all states reachable through instruction 1 either still fulfill Pre or 

h{tr, o,pc) := tr ={) A o{free) = True Ape = 2 
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where the latter implies 72 , 3 . As instruction 1 does not change the state when pc € {2,3} holds, 

h. 2 , 3 {tr, (y,pc) := Pre{tr, a,pc) V72,3(?0 
is an invariant for instruction 1 . 

Following a similar argumentation, 7 i, 2,3 is also an invariant for instructions 2 and 3, as neither does 
change the state where pc = I holds and neither sets pc = 1, so in the first case the validity of Pre 
is maintained, and in the latter case Pre as a disjunct (of the postcondition) can be ignored. The easy 
combination of disjuncts is due to the fact that all instruction labels are unique. The future proof calculus 
will make use of this property to combine invariants. 

As 7i 2,3 holds for both instruction 1 and instructions 2 and 3, we deduce using INV © that 7i 2.3 holds 
for all three instructions. As Inv follows from 7i 2 , 3 , we have shown that starting in Pre the validity of 
Inv is maintained by the program. 

We have shown how a preliminary Hoare calculus build on the denotational semantics can be used 
to reason about a nonterminating program. The proved property is an assertion about traces. Being able 
to show properties about traces will help to relate CUC and CSP. 


8 Conclusion 

In this paper, we have defined a compositional denotational semantics for a generic low-level language. 
Our denotational semantics is based on least fixpoints, it copes with communication, and it enables rea¬ 
soning about nonterminating programs. We have proved that it conforms to the more intuitive operational 
semantics of our language. We have analyzed our semantics with respect to compositionality and prefix 
closure and have demonstrated how it could be used to verify properties of unstructured code using a 
proof rule based on invariants. 

In future work, we aim at using our denotational semantics as the basis for a refinement proof calcu¬ 
lus that enables convenient conformance proofs between unstructured low-level programs and CSP-based 
specifications. To this end, we have based the behavioral semantics part within our denotational seman¬ 
tics on denotations as used in the CSP process calculus. To realize such a refinement proof calculus, we 
will first define a Hoare calculus for our semantics from which we have shown a preliminary rule. The 
refinement proof calculus will relate CSP processes and proof obligations in the Hoare calculus. To fully 
support CSP, we will extend the denotational semantics with concurrency in the form of an alphabetized 
parallel operator as in CSP, i.e., synchronous progress on shared events, otherwise interleaving. To not 
only be able to show safety properties but also liveness properties using such a refinement proof calculus, 
we want to extend the denotational semantics and the Hoare calculus to cope with failures. 
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